1. Field of the Invention
The present invention relates generally to the data processing field and, more particularly, to a computer implemented method, system and computer usable program code for end-to-end transaction tracking of long-running processes such as a Business Process Execution Language process using a combined flow-based/event-based approach.
2. Description of the Related Art
A Service-Oriented Architecture (SOA) is a collection of services that communicate with one another over a network in order to carry out business processes. Communication in an SOA can involve the simple passing of data or it can involve two or more services that coordinate some activity. Such services are loosely coupled (meaning that one application does not need to know the technical details of another application in order to communicate with the other application), have well-defined platform independent interfaces, and are reusable. In general, a service-oriented approach enables one or more businesses to link together fragmented data and business processes in order to create a more complete view of operations.
As the basis of an SOA, Business Process Execution Language (BPEL) provides a standard, portable language for orchestrating services into end-to-end business processes. Real world business processes involving multiple partners are generally long in duration considering the following factors:                1. Message exchange between business partners across corporate boundaries is often slow and unreliable;        2. Batch processing in legacy back-end systems may take a long time;        3. Data and/or transport conversions are often required and may take a long time; and        4. Long-running processes support human interactions in which case applications must often wait for the human interactions in order to proceed.        
In order to support long-running processes, individual invocations from each process are decoupled from an initial request in order to improve efficiency and to break up the processing into a recoverable set of transactions. Invocations are run in non-blocking threads. The response of an invocation is generated in a separate thread. In the special case of a one-way invocation, no response is generated.
Tracking response times of the various processes in an SOA is important to monitor and enable more efficient operation in the SOA. A flow-based approach to response time tracking tracks end-to-end response time by following the execution flow of distributed applications. Important transactions that compose the entire distributed flow are identified, tracked and correlated for each execution instance. Correlation tokens are simply passed from each upstream transaction (parent transaction) to its downstream transactions (children transactions) with the execution flow. This approach is sufficiently generic for all sorts of applications being instrumented without requiring special knowledge of individual applications or code changes. Therefore, it allows for tracking and correlating transactions that flow through a wide range of applications, and is critical for end-to-end response time tracking at instance level.
The flow-based transaction technique can effectively link BPEL artifacts (either synchronous or asynchronous) with IT end-to-end transaction tracking. In synchronous invocations, the flow-based approach provides accurate durations for transactions. However, in some asynchronous invocations, which return immediately after requests are placed in job queues, the response time measured using the flow-based approach will always be “0” even though the actual duration of the asynchronous invocation may be long.
Flow-based approaches can be improved with more correlation techniques; however, a long-running business process requires a deep knowledge of BPEL scripts and special internal correlation mechanisms only available from within business process engines.
Business processes described by BPEL are interpreted and executed by a BPEL engine. A BPEL engine manages the following:                Flow and control of the overall process        State persistence for long-running flows        Correlation of asynchronous messages        Correlation of process activities        Correlation of response with requests        Compensation        Exceptions        
The BPEL engine can be configured or instrumented to emit business events based on its knowledge of process/invocation state and correlation. Business events emitted by the process server contain process and invocation events already correlated at instance level. Event data (such as state and timestamp data) is stored in an event database and can be queried with instance IDs of business artifacts (such as processes, invoke activities, etc.).
A problem with a purely event-based approach to response time tracking is that instance data in the business process cannot be linked with transactions outside of the business process instance and with downstream IT resources. In other words, business process response time data cannot be linked into end-to-end transaction tracking.
There is, accordingly, a need for a mechanism for end-to-end transaction tracking of long-running processes such as a Business Process Execution Language (BPEL) process in a data processing system, such as a data processing system implemented in a Service-Oriented Architecture (SOA).